Generally and according to a first aspect the present invention relates to a system for handling the use of basic functions and supplementary functions in a telecommunication network including a plurality of users which can call each other and subscribe to basic services and supplementary functions relating to the basic and supplementary functions, respectively. A platform contains the basic functions and implements interfaces which each link one or more of the supplementary functions to the platform. Each supplementary function consists of one or more link modules, one per interface, that the supplementary function desires to use. Interaction logic is used for detecting and solving conflicts between supplementary functions.
More particularly, and according to a second aspect, the invention relates to a telecommunication system structured for including a set of basic functions and a set of supplementary functions. Each of said supplementary functions is connectable to a certain basic function for forming an addition to and modifying this basic function. The basic functions implement one or more open interfaces the functionality of which is not specific for any supplementary function, and which admit interaction between said basic functions and said supplementary functions in a way to allow new supplementary functions to be added to the system without affecting the basic functions. Interaction logic is used for solving problems arising from the respective behaviors of two supplementary functions, which are simultaneously connected to a specific basic function, coming into conflict with each other.
Commercial products in a telecommunication network usually have a set of basic functions which may be regarded as essential for that type of product. Basic functions may be said to distinguish different types of products from each other. A telephone must e.g. allow the user to establish calls in the network. A fax machine must be able to receive calls and write a message from the user from which the call originates. Besides these basic functions commercial Products usually offer some supplementary functions, which distinguish different products of the same type. Certain telephones may e.g. have a re-dial call button allowing the user to easily dial the number dialed last. Certain fax machines have the possibility to listen to recorded messages from anywhere in the network.
In the above defined connection there are certain concepts which may need clarification here and of which some are mentioned above and further below. These concepts are:
Network operator; this is an organization running a physical communication network. In Sweden Telia is an example. PA1 System manufacturer; this is an organization that has created and provides a communication network for the network operator. In Sweden this is Ericsson for Telia. In the Netherlands it is Ericsson and AT&T for Dutch PTT. PA1 User; this is a person or organization which can use a service in a communication network. The concept user is therefore not used without being related to a service or a group of services. Often a user is the same as a subscriber. PA1 Service provider; this is a person or organization providing a service for one or several users. Today's service provider normally is the same as the network operator, a condition that is expected to remain within a foreseable future. Service providers may also be users of services which are provided by another provider. PA1 Supplementary functions linked to the specific activation. PA1 Earlier operations of linked supplementary functions. PA1 Triggers which have been sent earlier to linked supplementary functions. PA1 The present operation/trigger. PA1 Information which may be stored in the platform and accessed by the coordination module. E.g. `call-state`. The coordination module can then perform coordinative actions for avoiding a conflict. This is called "solution logic". They include: PA1 Rescheduling execution of supplementary functions on a trigger. PA1 Ignoring, replacing or extending specific operations from certain supplementary functions, or certain triggers to certain supplementary functions. PA1 A great part of the execution of supplementary functions consists of operations towards the platform. A very detailed knowledge of the supplementary function is therefore required, probably more detailed than what is really needed for solving all possible conflicts of the supplementary functionality (no abstraction possible). PA1 If a certain data is required for a correct decision, this data has to be extracted from the operations ordered by the supplementary function. The data must be stored until requested by the interaction logic. Changes in the data must be monitored as well by extracting these changes from the subsequent operations. Beside the complexity with respect to supervision of the data and its changes, it once again requires a detailed knowledge about the internal way of operation of the supplementary function. PA1 All changes in the execution flow of a supplementary function must be carefully supervised by the detecting logic, if different branches in the execution flow may lead to different types of conflicts. A running state of the supplementary function must be maintained in the coordination module. Since decision logic and iteration logic cannot be monitored directly, operations and their data have to be interpreted for obtaining the necessary information. Once again this requires a detailed knowledge about the internal operation of the supplementary function. PA1 The execution flow in the supplementary function cannot be affected by other means than by returning a specific result for an operation, or sending triggers to the supplementary function. These results and triggers are not specific for the supplementary service. As a result of this the possibilities of affecting the behavior of the supplementary function are minimal. After a conflict has been solved it may be required that the supplementary function continues in another way than earlier. This is maybe not possible. The solution logic must then also take over all normal, not conflicting functions of the supplementary function, until the supplementary function can be trigged in another way so that it may be able to continue. In the meantime the supplementary function has to be blocked.
Each user in a telecommunication network uses it mainly for communicating with other users. In order for the user to be able to use the functions in the network e.g. establish a call, the user must subscribe, i.e. become a subscriber to applicable services. If a user desires to use basic functions of the system, the user must thus subscribe to the right basic services and if a user desires to use supplementary functions of the system the user has to subscribe to the right supplementary services.
By a subscription a specific service is thus provided for a user. The user, or the provider of the service on behalf of the user, may then activate a corresponding function. The function will then perform specific measures for the user. A call request is e.g. activated by lifting the telephone receiver. `Call Forwarding` is a feature which when activated will forward calls destined to the user for which the service is provided, to an alternative destination.
Since services are provided on a per user basis, the activated function should not have a greater influence on the system than what is determined by an agreement between the user and the provider of services as Dart of a service agreement. `Call Waiting` admits e.g. queuing of a call to a busy access. When the service is provided the accesses for which `Call Waiting` may queue calls is limited to the access that the user hires from the provider. This function is therefore said to be "activated for the access", by a user owning the access. If the access is owned by several users which is e.g. possible in ISDN, only such calls will be queued which are destined for the user having activated `Call Waiting`.
The concepts of basic functions and supplementary functions, in the meaning here used, as well as the interactions discussed more closely below, are well known in the art. Shortly, each basic function and supplementary function is a code executed by computers in the telecommunication system. Activation of a desired supplementary service is performed by a jump instruction in the code of the executed basic function.
Recommendations relating to and describing basic functions and supplementary functions occur e.g. within the GSM system. Reference may e.g. be made to recommendation 02.04 regarding the above used denominations such as `Call Waiting` etc. for some different supplementary functions.
In connection with the description of supplementary functions which may be exposed to the interaction problem there is also a description of the interaction in question and its consequence.
There may also be supplementary functions which are applicable only for the service provider, i.e. no user has access to such supplementary functions. The service provider need not subscribe to a service until these supplementary functions are activated. Many supplementary functions for network maintenance are e.g. activated for a transmission route: supplementary functions introducing priority lines within the transmission route, or supplementary functions automatically blocking the route under certain conditions. Also users may lease transmission routes, or rather a user representing a group of users, e.g. a business group. In this case the user must subscribe to a service before any supplementary functions may be activated by the user relating to this transmission route.
The more services that are available the more attractive is a provider of these services for "potential" users. It is therefore essential for the provider to be able to offer a competitive set of services, basic services as well as supplementary services. Offering new supplementary services is regarded to be the fastest way of attaining this due to the fact that implementation of the included supplementary service only requires small modifications of the basic function. A large widening of the number of supplementary services may therefore be expected. This requires a short cycle of introduction, i.e. from the rise of the need until the installation, of new supplementary services. Since the providing and activating principles are very straight forward it will be the supplementary service part that may form an obstacle to attain short introduction cycles. These supplementary services are therefore mostly implemented as software.
To change a complete telecommunication system each time a new supplementary service is introduced is too expensive. A mimimum requirement on a system is therefore that it must be modular. A modular system admits introduction of new and removal of old supplementary functions without affecting other installed supplementary functions. Each supplementary function is installed as a separate loading module.
This modularity may be attained by means of a platform. The platform contains the basic functions. It also implements one or more interfaces. Each interface links one or more supplementary functions to the basic functions which admits interaction between the supplementary and basic functions.
A supplementary function can consist of one or more link modules, one for each interface, that the supplementary function desires to use. A link module is a module that can be linked to an interface without affecting, in connection with the linking, other modules which are linked to the same interface.
Each interface consists of operations and triggers. Triggers are calls to operations which when executed perform specific changes in the behavior of the basic function. When these changes appear the corresponding trigger is sent to the supplementary services linked to the interface. Each supplementary service can then react on the trigger by ordering the platform to execute one or more operations. The platform will schedule the execution of the supplementary services, i.e. decide in what order supplementary services shall receive the trigger.
This results in a two way interaction between platform and supplementary services.
The interface is open, by which it is meant in the present connection that it shall be generic for all services, as well as be able to be used by more than one service in the same system. In other words, there are no operations or triggers which are specific for any supplementary service. The platform itself must not contain any code specific for any supplementary service. Future upgradings of the platform must implement interfaces which are compatible with previous versions. These properties secure modularity between the platform and the supplementary functions. The supplementary functions can be installed, designed and upgraded without affecting the platform, and the platform can be upgraded without affecting the supplementary functions.
Most users will only have activated a few supplementary functions. It is therefore important that the handling of triggers is optimized for avoiding a lot of overhead in the processor capacity. For each activation of a basic function, e.g. at a call or an operator procedure, a trigger should thus only be received by those supplementary functions which are applicable for this specific activation. This can be attained by building the link picture, stating the supplementary functions which are linked to an interface, during the execution of the basic function itself. Only supplementary functions which are activated will then be linked and triggers will only be sent to them. If a certain call e.g. includes a transmission route, for which a supplementary function is activated, then the appropriate link module in this supplementary function will be linked to the call. The supplementary function can now receive triggers from the call. This procedure is often referred to as "dynamic linking". For further optimization triggers may be sent only to a subset of the linked supplementary functions, viz. those that have indicated interest for this trigger. Such a mechanism is called "monitoring".
Dynamic linking is not unusual. In C++ the principle for "dynamic binding" can be used for implementing dynamic linking. In PLEX signals carry their destination as dynamic data (the mechanism used for communicating between modules). In AXE-10 this function included in PLEX is used for implementing a "traffic link" (=an active call), where the modules can be "in-linked" or "side-linked" (=dynamic linking).
The conventional technique within the art suffers from some problems.
Once a platform has been implemented as described above, modularity is attained between supplementary function and platform. By using the same platform, unfortunately supplementary functions may end in a conflict with respect to their mutual behaviors. As a possible solution to the conflict between two or more supplementary functions it is known to design the supplementary functions affected by the conflict so that they interact with each other in order to solve the conflict. Between supplementary functions in this structure there are thus no natural modularity preventing conflicts to appear. Compare e.g. `Call Forwarding on Busy` and `Call Waiting`. `Call Forwarding on Busy` forwards a call if the user is busy. `Call Waiting` will instead queue a call for the busy user. The two supplementary functions must interact to come to an agreement. Both can e.g. be activated, but if the original destination answers first, ringing to the alternative destination is stopped, and if the alternative destination answers first, the call will be removed from the `Call Waiting` queue.
As long as there are not so many supplementary functions in the system, interactions may be quite simply implemented in the supplementary functions themselves. With a growing number of supplementary functions the total introduction cycle for each new supplementary function becomes longer because more and more already installed supplementary functions have to be upgraded. This can result in an introduction disturbance in the system. This problem is often referred to as "interaction problem". Each solution must guarantee modularity between all supplementary functions. The invention starts from the realization that interactions should not be implemented in the supplementary functions proper. Of course the way this is performed must not create more problems than it solves.
In a traditional architecture the coordination mechanism, in the form of software solving conflicts between supplementary functions, is logically a part of the platform, but is implemented as a separate module, i.e. it can be upgraded separately. From the point of view of a supplementary function the coordination module belongs to the platform. As long as no coordination is required the coordination module will only forward ordered operations from supplementary functions to the platform and forward triggers from the platform to one or more supplementary functions. The coordination module will also perform the dynamic linking required.
The coordination module will detect a conflict either when a supplementary function provides an operation or when the platform sends a trigger. The logic detecting a conflict is referred to as "detection logic" and has access to the following information:
This traditional approach leads to a loose relationship between the supplementary function logic and interaction logic, i.e. detecting logic plus solution logic, of this supplementary function. As a result, no supplementary function related data or code is directly accessible by the coordination module, except for data stored in the platform, e.g. a data base. Not even data in the data base can be secure. Supplementary functions often copy this data during execution and then uses this copy for further processing. Another consequence of this structure is that there does not exist any feed back to the supplementary function. The supplementary function does therefore not know whether the operations ordered thereby are executed unmodified, or if it did not receive a monitored trigger. As a consequence of this supplementary functions are as simple as possible, but the interaction logic will consequently be more complicated. The involved complications are:
Some of the described negative effects may be partly compensated for. A supplementary function may e.g. send certain information to the coordination module, such as a permission to state decision flow in the supplementary function. Since the supplementary function is not conscious of when this information should need to be applied, it must always be sent. This leads to an ineffective use of memory and processor capacity. Another possibility is to avoid the negative effects by only stating simple interactions. Such interactions are often controlled by priorities which are assigned to the supplementary functions. These priorities decide scheduling of the supplementary functions (higher priority before a lower priority) or may lead to blocking of low priority supplementary functions. Systems using this architecture have in practice turned out to be rather successful in handling these simple interactions, since the interaction logic quite easily may be controlled by tables. One example is the desired interaction between `Call Forwarding on Busy` and `Call Waiting`. Both act on a trigger `Busy Access`. `Call Forwarding` would then transfer the call to an alternative destination, whereas `Call Waiting` would queue the call for the access until it becomes available. The interaction could consist in blocking `Call Forwarding` so that the call instead is queued.
"More intelligent" solutions are however often preferred. In the case of `Call Forwarding` and `Call Waiting` one could e.g. decide to do both and let the interaction decide based upon the part answering the call first. This could e.g. require the possibility of eliminating `Call Waiting` if the alternative destination answers. Another possibility is to transfer the call if `Call Waiting` for some reason is not successful, e.g. because no resources are available for sending a tone to the user, or due to time out from the user. This could require sending the `Busy` trigger again, but only to `Call Forwarding`, and only if the present state of the call would be compatible with `Call Forwarding`.
The design of the supplementary function thus becomes simpler but the design of the interaction logic becomes more complicated as a result. This was acceptable when there were not so many supplementary functions installed. Providers of services usually have no strict demands for interactions, and therefore most interactions are kept as simple as possible. As users become more conscious of available and potential supplementary functions they require more supplementary functions faster, and more complicated interactions.
U.S. Pat. No. 5,115,432 describes an architecture for data communication adapted for communication over (high speed) networks. By data communication is here intended e.g. file, voice or video data. The architecture consists of two levels. The higher level consists of a number of independent "horizontal functions" which are performed in parallel. The lower level consists of basic functions towards the network. All low level functions and correpsonding processes are performed in a function for controlling access to the network. Dependencies, if any, between the horizontal functions are solved by means of a function intended therefore. The architecture thus offers these "horizontal functions" to interact on a level different from this low level.
EP 228,053 relates to a method for controlling a telecommunication system in real time. A structure is described which admits that supplementary functions may be easily modified/programmed and that interactions between different supplementary functions may be solved in a simple way. The solution according to the document is that the programs are written by means of "scripts" in a "non procedural language" and consist of a number of triplets. The interaction between these "scripts" admits that "scripts" with a higher level may allow "scripts" on a lower level to be implemented if its triplets indicate this.
U.S. Pat. No. 4,928,304 describes an electronic exchange system for a telecommunication network in the form of a telephone switch and an external computer connected thereto. Program sequences necessary for standard functions are stored in memory units in the telephone switch. Programs for performing services which are only available for part of the subscribers, are stored in the external computer. Via the external computer it is possible, by means of a computer interface, to control specific functions of the telephone switch. This architecture implies that changes of the different supplementary functions may be easily done by making changes in the programs of the external computer.